In some environments you don't have complete control of how the configuration will be changed. This is particularly true in component based environments. This situations can be views from two different poins of view
EasyConf has specific functionality to support these necessities in a very simple way. If you are the developer of a component, you can distribute it with a base configuration file (for example my-component.properties). It is recommended that you place it so that it will be included in the application classpath. If you distribute the application as a JAR file, just put it in the root of the JAR. If you distribute it as a WAR file, place it in the WEB-INF/classes subdirectory. For other kinds of distribution files refer to its documentation to find a place that will be included in the classpath when the component is deployed.
On the other side, if you need to aggregate several components which have been configured using EasyConf you can override the the properties of any of them in one single file: global-configuration.properties.
The name of this file is fixed by EasyConf (it is one of its conventions), but you can include other files using the include-and-override special property. This allows you to effectively change its name: just include the file with your desired name and do not set any property in the global-configuration.properties.
The properties are specified in the global-configuration.properties (or any of its included files) in the same way as they are in the base configuration file. But it is possible to prefix the property names with the name of the component to prevent collision of names among different components. The component name is separated from the property name by the : character.
For example to override the default value of the property skin of the component my-component you should add the following line:
my-component:skin=purple
The following image shows how this process works in a diagram:
In blue, a client application asks for the configuration of component moduleABC. When it asks for a specific property (hidden in the diagram for simplicity) EasyConf checks if the property is present in global-configuration.properties (or any of its included files, of course). If not it will read the values in moduleABC.properties. In red, a different client asks for the configuration of a different component, moduleXYZ. But once again EasyConf checks first the global-configuration.properties file and only if a property is not found it looks for it in moduleXYZ.properties
You have a portlet named reports which shows data present in a database table. You use the portlet name as the configuration component name, so you can configure it with the property file named reports.properties. It may have the following contents:
database.url=jdbc:mysql://localhost/database
table=reports
primary-key=reportid
Then you have a second portlet named banner which shows a configured banner, the image can be shown inside a table or by itself. Following the same convention of the previous portlet the configuration is specified in the file banner.properties.
img=image.jpg
url=http://easyconf.sourceforge.net
table=false
Both portlets are released and someone chooses to deploy them in her portal, but the default configuration doesn't fit her needs. Because the portlets have been configured using EasyConf he can just override the specific properties needed in a single file: global-configuration.properties. In this case the aggregator wants to set a different database.url for the reports portlet and a different url for the banner portlet, so he sets the desired properties in the global-configuration.properties file as follows:
reports:database.url=jdbc:mysql://my-db-server/my-database
banner:url=http://maven.apache.org
It's that simple. The original portlet distribution has not been modified and updates to new releases will cost nothing (unless the property names have changed). Note that prefixing the the property with the component name (reports or banner in this example) is optional, but is highly recommended to avoid name collision.
All component based environments will find this functionality useful. There are other strategies to achieve this behaviour such as providing a method to configure the component passing a Properties or a custom made object. EasyConf also allows implementing component configuration this way, but the file based approach is offered for those cases where it is considered more appropriate. Situations in which you may opt to use this approach are: